1. Field of the Disclosure
The technology of the disclosure relates generally to Web Real-Time Communications (WebRTC) interactive sessions.
2. Technical Background
Web Real-Time Communications (WebRTC) represents an ongoing effort to develop industry standards for integrating real-time communications functionality into web clients, such as web browsers, to enable direct interaction with other web clients. This real-time communications functionality is accessible by web developers via standard markup tags, such as those provided by version 5 of the Hypertext Markup Language (HTML5), and client-side scripting Application Programming Interfaces (APIs), such as JavaScript APIs. More information regarding WebRTC may be found in “WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web,” by Alan B. Johnston and Daniel C. Burnett, 2nd Edition (2013 Digital Codex LLC), which is incorporated herein in its entirety by reference. WebRTC provides built-in capabilities for establishing real-time video, audio, and/or data streams in both point-to-point interactive sessions and multi-party interactive sessions. The WebRTC standards are currently under joint development by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF). Information on the current state of WebRTC standards can be found at, e.g., http://www.w3c.org and http://www.ietf.org.
To establish a WebRTC video, audio, and/or data exchange, two WebRTC clients, such as WebRTC-enabled web browsers, may retrieve WebRTC-enabled web applications from a WebRTC application server. Through the web applications, the two WebRTC clients engage in a WebRTC offer/answer exchange of Session Data Protocol (SDP) objects or other data objects used to describe the WebRTC media and/or data streams to be established via a signaling (i.e., non-media related) channel. The objects are used by the WebRTC clients to communicate and reach an agreement on parameters that define characteristics of the WebRTC interactive session. Once the WebRTC offer/answer exchange is complete, the WebRTC clients may then establish a direct peer connection with one another, and may begin an exchange of media or data packets transporting the real-time communications.
WebRTC requires media packets being exchanged in a real-time interactive media session to be encrypted. Typically, the Secure Real-time Transport Protocol (SRTP), defined in RFC 3711, is used to provide a secure real-time media flow. Two keying mechanisms are currently employed by WebRTC clients to generate a symmetric cryptographic key (i.e., a secret key used by both WebRTC endpoints) to encrypt WebRTC media. The first mechanism, known as SDP Security Descriptions (SDES) and defined in RFC 4568, transmits a key from one WebRTC client to another as part of an SDP object exchanged during a WebRTC offer/answer exchange over a signaling channel, which passes through one or more intermediate servers. Another keying mechanism is Datagram Transport Layer Security for SRTP (DTLS-SRTP), defined in RFC 5764. Instead of including a key during the WebRTC offer/answer exchange, DTLS-SRTP generates or exchanges a key in a media channel separate from the signaling channel used for the WebRTC offer/answer exchange. The most secure approach generates a key based on a Diffie-Hillman (DH) key exchange between the WebRTC clients. Because the key used for encryption is never sent over the signaling channel through intermediate servers, but rather is transmitted directly between the WebRTC clients, DTLS-SRTP offers a higher level of security than SDES.
However, neither SDES nor DTLS-SRTP can guarantee privacy of a WebRTC media channel against a “man-in-the-middle” (MitM) attacker. A MitM attacker may be a third party that eavesdrops on communications between two WebRTC clients by secretly interposing itself in a WebRTC media channel between the WebRTC clients. As illustrated in FIG. 1, a MitM attacker 10 may intercept communications between WebRTC clients 12 and 14 by covertly establishing two WebRTC media channels: a MitM WebRTC media channel 16 for a compromised WebRTC media flow 18 with the WebRTC client 12, and a MitM WebRTC media channel 20 for a compromised WebRTC media flow 22 with the WebRTC client 14. In doing so, the MitM attacker 10 makes it appear that the WebRTC clients 12 and 14 are communicating directly via an apparent WebRTC media flow 24 over an apparent WebRTC media channel 26, when in fact the MitM attacker 10 is secretly eavesdropping on the communications. SDES provides no protection against the MitM attacker 10 because the key intended to encrypt the WebRTC media channel 26 could be intercepted and subsequently stored or changed by the MitM attacker 10. Likewise, DTLS-SRTP alone offers no guarantee of privacy because the MitM attacker 10 could carry out a DH key exchange with each of the WebRTC clients 12 and 14, while making it appear that they are conducting a DH key exchange with each other.